HTTP 쿠키
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
HTTP 쿠키는 웹 서버가 사용자의 웹 브라우저에 저장하는 작은 데이터 조각으로, 사용자의 웹 브라우징 정보를 저장하고 웹사이트에서 사용자를 식별하는 데 사용된다. 1994년 넷스케이프의 직원에 의해 개발되었으며, 세션 관리, 개인화, 웹 추적 등 다양한 목적으로 활용된다. 쿠키는 세션 쿠키, 영구 쿠키, 보안 쿠키 등 여러 종류가 있으며, 이름과 값, 속성으로 구성된다. 쿠키는 세션 하이재킹, 사이트 간 요청 위조, 개인 정보 침해 등의 보안 및 개인 정보 보호 문제를 야기할 수 있으며, 이에 대한 대안 기술 및 법적 규제가 존재한다. 사용자들은 웹 브라우저 설정을 통해 쿠키 사용을 제어할 수 있다.
더 읽어볼만한 페이지
- 추적 - 감시 자본주의
감시 자본주의는 기업이 사용자 행동 데이터를 수집, 분석하여 이윤을 얻는 새로운 자본주의 형태로, 개인 정보 침해 및 사회적 불평등 심화 등의 문제점을 야기하여 국제적인 규제 논의가 이루어지고 있다. - 추적 - 미사일 유도
미사일 유도는 목표 지점까지 미사일을 정확하게 유도하는 기술로, 초기 비행기 폭탄 원격 유도 시도에서 시작되어 제2차 세계 대전 중 독일의 보복무기 개발, 냉전 시대 탄도 미사일 경쟁을 거치며 발전해 현대에는 GPS, 레이저, 적외선 등 다양한 유도 방식이 융합되어 사용된다. - HTTP - HTTPS
HTTPS는 HTTP에 보안 기능이 더해진 통신 규약으로, 웹 브라우저와 서버 간 통신을 암호화하여 보안을 강화하지만, 인증서 비용, 서버 부하, 혼합 콘텐츠 문제 등의 단점도 존재한다. - HTTP - 웹 캐시
웹 캐시는 웹 서버와 클라이언트 사이에서 웹 요청 응답을 저장하고 재사용하여 웹 페이지 로딩 속도를 개선하는 기술로, HTTP 프로토콜을 통해 제어되며, 디지털 밀레니엄 저작권법과 한국의 인터넷 환경에서 중요한 역할을 한다. - 웹 취약점 공격 - 보안 취약점
보안 취약점은 시스템의 설계, 구현, 운영, 관리상 결함이나 약점으로, 위협에 의해 악용되어 시스템 보안 정책을 위반할 수 있는 요소이며, ISO 27005, IETF RFC 4949, NIST SP 800-30, ENISA 등 다양한 기관에서 정의하고 있다. - 웹 취약점 공격 - 인터넷 보안
인터넷 보안은 사이버 위협, 악성 소프트웨어, 서비스 거부 공격 등으로부터 정보와 시스템을 보호하기 위해 네트워크 계층 보안, 다단계 인증, 방화벽 등 다양한 기술과 방법을 포괄한다.
HTTP 쿠키 | |
---|---|
개요 | |
종류 | 세션 쿠키 영구 쿠키 |
기술적 정보 | |
목적 | 웹 브라우저에 저장되는 작은 데이터 조각 |
사용 | 세션 관리 개인 설정 사용자 추적 |
세션 관리 | |
설명 | 서버가 사용자를 식별하고 상태를 유지하는 데 사용됨 |
개인 설정 | |
설명 | 사용자 선호도 및 설정을 저장하는 데 사용됨 |
사용자 추적 | |
설명 | 웹 사이트 전반에 걸쳐 사용자 행동을 모니터링하는 데 사용됨 |
보안 문제 | |
취약점 | HTTP 헤더 인젝션 HTTP 요청 스머글링 HTTP 응답 분할 HTTP 파라미터 오염 |
해결책 | HTTPS 사용, 쿠키 속성 설정 (Secure, HttpOnly 등) |
규제 | |
EU 쿠키 지침 | 웹사이트가 쿠키 사용에 대한 동의를 얻도록 요구 |
미국 추적 금지 법안 | 온라인 광고에 대한 추적 금지 |
기타 | |
관련 용어 | 세션 ID 로컬 스토리지 웹 스토리지 |
2. 역사
HTTP 쿠키는 1994년 루 몬툴리가 웹 통신에 사용하면서 시작되었다.[127] 당시 넷스케이프 커뮤니케이션스에서 전자 상거래 애플리케이션을 개발하던 그는 MCI의 요청으로 서버가 아닌 사용자 컴퓨터에 거래 상태를 저장하는 방법을 고안해야 했다. 그 해결책으로 가상 쇼핑 카트 구현에 쿠키가 사용되었다.[128][129]
HTTP는 원래 하이퍼텍스트 전송을 위한 상태 비저장 프로토콜로, 동일한 URL은 동일한 정보원[107]을 제공했다. 그러나 월드 와이드 웹 확산으로 상황에 따라 다른 페이지를 제공해야 할 필요성[108]이 생겼다.
IP 주소나 고유 URL을 사용하는 방법도 있었지만, 1994년 넷스케이프 커뮤니케이션즈는 쿠키[109]를 제안, 구현했다. 쿠키는 서버가 HTTP 헤더에 식별자를 담아 브라우저에 보내고, 브라우저는 이를 저장 후 다음 통신 때 서버에 보내는 방식으로 HTTP에서 상태 저장을 가능하게 했다.
이후 쿠키는 여러 표준화 과정을 거쳤다.
RFC 문서 | 발표 시기 | 내용 |
---|---|---|
RFC 2109 | 1997년 2월 | 최초의 쿠키 표준 |
RFC 2965 | 2000년 10월 | RFC 2109 대체, `Set-Cookie2` 헤더 필드 추가 |
RFC 6265 | 2011년 4월 | `Set-Cookie2` 사용 중단, 현재 사용되는 쿠키 명세 |
대부분의 웹 서버와 웹 브라우저에서 쿠키를 지원하며, 2016년부터 RFC 6265 개정 작업이 진행 중이다.[112]
2. 1. 이름의 기원
"쿠키"라는 용어는 웹 브라우저 프로그래머 루 몬툴리가 만들었다. 이는 유닉스 프로그래머들이 사용하던 매직 쿠키라는 용어에서 비롯된 것이다. 매직 쿠키는 프로그램이 수신 후 변경하지 않은 채로 반환하는 데이터 패킷을 의미한다.[125][126]2. 2. 초기 역사
"쿠키"라는 용어는 웹 브라우저 프로그래머 루 몬툴리가 만들었다. 이는 유닉스 프로그래머들이 사용하던 용어인 매직 쿠키에서 유래되었는데, 매직 쿠키는 프로그램이 받아서 변경하지 않고 그대로 반환하는 데이터 패킷을 의미한다.[125][126]
1994년 6월, 넷스케이프 커뮤니케이션즈의 직원이었던 루 몬툴리는 웹 통신에 매직 쿠키를 활용할 아이디어를 떠올렸다.[8] 당시 넷스케이프는 MCI를 위한 전자 상거래 응용 프로그램을 개발 중이었다. 빈트 서프와 존 클렌신은 넷스케이프와의 기술 논의에서 MCI를 대표했는데, MCI는 자사 서버가 부분적인 거래 상태를 유지하는 것을 원하지 않았다. 그래서 MCI는 넷스케이프에 각 사용자 컴퓨터에 거래 상태를 저장하는 방법을 요청했고, 이는 가상 쇼핑 카트를 안정적으로 구현하는 문제에 대한 해결책이 되었다.[9][10]
루 몬툴리는 존 지안난드레아와 함께 최초의 넷스케이프 쿠키 명세를 작성했다. 1994년 10월 13일에 출시된 모자이크 넷스케이프 버전 0.9 베타는 쿠키를 지원했다.[11][12] 넷스케이프 웹사이트에서 쿠키가 처음 사용되었는데, 방문자가 이전에 사이트를 방문했는지 확인하는 용도였다. 루 몬툴리는 1995년에 쿠키 기술에 대한 특허를 신청하여 1998년에 특허를 받았다.[13] 인터넷 익스플로러는 1995년 10월에 출시된 버전 2부터 쿠키를 지원하기 시작했다.[14]
2. 3. 표준화 과정
인터넷 기술 태스크 포스(IETF) 내에 특별 작업 그룹이 결성되어 쿠키 표준화가 진행되었다. 1997년 2월, RFC 2109가 발표되었는데, 이 명세는 서드 파티 쿠키를 아예 허용하지 않거나 기본적으로 활성화하지 않도록 규정했다.[17] 그러나 당시 광고 회사는 이미 서드 파티 쿠키를 사용하고 있었고, RFC 2109의 권장 사항은 넷스케이프와 인터넷 익스플로러에서 지켜지지 않았다.RFC 2109는 2000년 10월 RFC 2965로 대체되었다. RFC 2965는 `Set-Cookie2` 헤더 필드를 추가했는데, 이는 비공식적으로 "RFC 2965 스타일 쿠키"라고 불렸고, 원래의 `Set-Cookie` 헤더 필드는 "넷스케이프 스타일 쿠키"라고 불렸다.[18][19]
그러나 `Set-Cookie2`는 거의 사용되지 않았고, 2011년 4월 RFC 6265에서 사용 중단되었다.[20] RFC 6265는 실제 사용되는 쿠키에 대한 최종적인 명세로 작성되었으며, 현대 브라우저는 `Set-Cookie2` 헤더 필드를 인식하지 못한다.[21]
RFC 2109 및 RFC 2965는 넷스케이프 사양과 `Expires` 속성에서 `Max-Age` 속성으로의 변경 등 호환성이 없어, 실제 웹사이트에서는 거의 사용되지 않았다.[110] `Expires` 속성 등에서 사용되는 날짜 형식은 사양 외의 기술이 범람하고 있었고,[111] 보안상의 이유로 `httponly` 속성이나 `secure` 속성 등이 사실상 추가되었으며, 오랫동안 문서가 없는 상태가 지속되었으나, RFC 6265는 이러한 문제를 해결하고자 제정되었다.
2016년경부터 RFC 6265의 개정 작업이 진행되고 있다.[112] 쿠키 접두사(
__Secure-
및 __Host-
), SameSite 속성의 추가 등이 예정되어 있으며, 이미 웹 브라우저에서의 구현도 병행하여 진행되고 있다.[113][114]2. 4. 최근 동향
2016년경부터 IETF RFC|6265영어의 개정 작업이 진행되고 있다.[112] 쿠키 접두사(__Secure-
및 __Host-
), SameSite 속성의 추가 등이 예정되어 있으며, 이미 웹 브라우저에서의 구현도 병행하여 진행되고 있다.[113][114]3. 쿠키의 종류
HTTP 쿠키는 기능을 수행하는 방식과 목적에 따라 여러 종류로 나뉜다.
쿠키는 보통 브라우저를 종료하면 사라지지만, 특정 기간 동안 유지되도록 설정할 수도 있다. 하지만 2038년 문제[115] 때문에 2038년 1월 19일 이후를 만료일로 지정하는 경우는 드물다.
- 보안 쿠키 (Secure cookie): HTTPS와 같이 암호화된 연결에서만 전송되는 쿠키이다. 도청을 통한 쿠키 탈취 위험을 줄여준다.[1]
- HttpOnly 쿠키: 자바스크립트와 같은 클라이언트 측 API로는 접근할 수 없는 쿠키이다. 크로스 사이트 스크립팅(XSS)을 통한 쿠키 도난 위협을 줄여주지만,[26] 크로스 사이트 트레이싱(XST) 및 크로스 사이트 요청 위조(CSRF) 공격에는 취약하다.
- SameSite 쿠키: 사이트 간 요청 위조 (CSRF) 공격을 완화하기 위해 도입된 쿠키이다. `SameSite` 속성 값에 따라 쿠키 전송 범위가 달라진다.[28]
- `Strict`: origin 도메인과 동일한 대상 도메인에만 쿠키를 전송한다.[29]
- `Lax`: origin 도메인과 달라도 GET과 같은 안전한 요청에는 쿠키를 전송한다.
- `None`: 타사(사이트 간) 쿠키를 허용하지만, 대부분의 브라우저는 보안 속성을 요구한다.[30]
- 서드 파티 쿠키 (Third-party cookie): 현재 주소 표시줄의 도메인과 다른 도메인에 속하는 쿠키로, 주로 배너 광고와 같은 외부 콘텐츠에 포함되어 나타난다.[64] 사용자의 브라우징 기록을 웹 추적하여 행동 타겟팅 광고 등에 활용되며, 필터 버블의 원인이 되기도 한다. 이는 개인 정보 침해 논란을 일으킨다.[117][118]

- 슈퍼쿠키 (Supercookie): 최상위 도메인 (예: `.com`) 또는 공용 접미사 (예: `.co.uk`)를 기원으로 하는 쿠키이다. 일반 쿠키보다 넓은 범위에 영향을 줄 수 있어 보안 문제가 될 수 있다.
- 좀비 쿠키 (Zombie cookie): 삭제 후에도 자동으로 재생성되는 쿠키이다. Local Shared Object (플래시 쿠키), 웹 스토리지(HTML5 Web storage) 등 다양한 위치에 저장되어 사용자가 인지하기 어렵고, 쿠키가 거부되거나 삭제되어도 쉽게 복원된다.[40][41][119]
3. 1. 세션 쿠키 (Session cookie)
'''세션 쿠키'''(인 메모리 쿠키, 임시 쿠키 또는 비영속 쿠키라고도 함)는 사용자가 웹사이트를 탐색하는 동안 임시 메모리에만 존재한다.[22] 사용자가 웹 브라우저를 닫으면 만료되거나 삭제된다.[23] 세션 쿠키는 브라우저에서 만료일이 할당되지 않음으로써 식별된다.3. 2. 영구 쿠키 (Persistent cookie)
영구 쿠키는 특정 날짜 또는 특정 기간이 지나면 만료된다. 영구 쿠키의 수명은 생성자가 설정하며, 해당 쿠키의 정보는 사용자가 쿠키가 속한 웹사이트를 방문할 때마다 또는 사용자가 다른 웹사이트에서 해당 웹사이트에 속한 리소스(예: 광고)를 볼 때마다 서버로 전송된다.이러한 이유로 영구 쿠키는 때때로 트래킹 쿠키[24][25]라고 불리는데, 광고주가 사용자의 웹 브라우징 습관에 대한 정보를 장기간 기록하는 데 사용할 수 있기 때문이다. 영구 쿠키는 사용자가 웹사이트에서 자신의 계정에 로그인된 상태를 유지하여 매 방문 시마다 로그인 자격 증명을 다시 입력하지 않도록 하는 등 여러 가지 이유로 사용된다.
쿠키를 설정할 때, 어떤 요청에 대해 쿠키 정보를 다시 보낼지 URL 범위를 지정한다. 기본값은 쿠키를 설정한 서버에 대한 모든 요청이며, 범위를 넓히거나 좁힐 수도 있다. 하지만 범위를 넓히는 경우에도 최상위 도메인보다 좁은 범위여야 한다.
또한 쿠키의 유효 기간은 보통 브라우저를 종료할 때까지이지만, 지정된 기한까지는 브라우저를 다시 시작해도 유지되도록 설정할 수 있다. 유효 기간 정보는 서버에서 브라우저로 쿠키 정보를 전송하는 단계에서 추가된다.
무기한 설정은 불가능하다. 아주 먼 미래를 지정하여 반영구적으로 유효하게 할 수도 있지만, 브라우저나 서버가 2038년 문제로 인해 문제를 일으킬 수 있으므로[115], 2038년 1월 19일 3시 14분 07초(UTC) 이후의 시간을 기한으로 설정하는 경우는 드물다.
3. 3. 보안 쿠키 (Secure cookie)
보안 쿠키(Secure cookie)는 HTTPS와 같이 암호화된 연결을 통해서만 전송될 수 있는 쿠키이다. HTTP와 같이 암호화되지 않은 연결을 통해서는 전송될 수 없다. 이렇게 하면 도청을 통한 쿠키 탈취에 노출될 가능성이 줄어든다. 쿠키에 `Secure` 플래그를 추가하여 쿠키를 안전하게 만들 수 있다.[1]3. 4. HttpOnly 쿠키
`HttpOnly` 쿠키는 자바스크립트와 같은 클라이언트 측 API에서 접근할 수 없다. 이러한 제한은 크로스 사이트 스크립팅(XSS)을 통한 쿠키 도난의 위협을 제거한다.[26] 그러나 쿠키는 크로스 사이트 트레이싱(XST) 및 크로스 사이트 요청 위조(CSRF) 공격에는 취약하다. 쿠키는 `HttpOnly` 플래그를 추가하여 이러한 특성을 갖게 된다.3. 5. SameSite 쿠키
2016년 구글 크롬 버전 51에서 `SameSite` 속성을 가진 새로운 종류의 쿠키가 도입되었으며, 가능한 값은 `Strict`, `Lax`, `None`이다.[28] `SameSite=Strict` 속성을 사용하면 브라우저는 origin 도메인과 동일한 대상 도메인에만 쿠키를 전송한다. 이는 사이트 간 요청 위조 (CSRF) 공격을 효과적으로 완화한다.[29] `SameSite=Lax`를 사용하면 브라우저는 origin 도메인과 달라도 GET과 같은 '안전한' 요청(POST는 안전하지 않음)과 iframe 내부의 타사 쿠키가 아닌 요청으로 쿠키를 대상 도메인에 전송한다. `SameSite=None` 속성은 타사(사이트 간) 쿠키를 허용하지만, 대부분의 브라우저는 `SameSite=None` 쿠키에 보안 속성을 요구한다.[30]Same-site 쿠키는 RFC 6265를 업데이트하기 위한 "쿠키: HTTP 상태 관리 메커니즘"에 대한 새로운 RFC 초안에 통합되었다.[31]
크롬, 파이어폭스 및 엣지는 Same-site 쿠키를 지원하기 시작했다.[32] 롤아웃의 핵심은 `SameSite` 속성이 정의되지 않은 기존 쿠키의 처리 방식이다. 크롬은 이러한 기존 쿠키를 `SameSite=None`과 동일하게 처리하여 모든 웹사이트/애플리케이션이 이전과 동일하게 실행되도록 했다. 구글은 이 기본값을 2020년 2월 출시 예정인 크롬 80에서 `SameSite=Lax`로 변경하려 했지만,[33] 타사/사이트 간 쿠키에 의존하는 애플리케이션/웹사이트의 중단 가능성과 코로나19 상황으로 인해 구글은 이 변경을 크롬 84로 연기했다.[34][35]
3. 6. 서드 파티 쿠키 (Third-party cookie)
서드 파티 쿠키는 주소 표시줄에 표시된 도메인과 다른 도메인에 속하는 쿠키를 말한다. 이러한 쿠키는 일반적으로 웹 페이지에 배너 광고와 같은 외부 웹사이트의 콘텐츠가 포함될 때 나타난다.[64] 예를 들어, 사용자가 `www.example.org`를 방문했을 때 `ad.foxytracking.com`의 광고가 다운로드되면, 광고 도메인(ad.foxytracking.com
)에 속하는 쿠키가 설정된다. 이후 사용자가 `www.foo.com`과 같이 `ad.foxytracking.com`의 광고가 포함된 다른 웹사이트를 방문하면, 해당 도메인에 속하는 또 다른 쿠키가 설정된다. 결국, 광고를 로드하거나 해당 웹사이트를 방문할 때 이 두 쿠키가 광고주에게 전송된다. 광고주는 HTTP 리퍼러 헤더 필드를 사용하여 사용자의 브라우징 기록을 구축할 수 있다.[64]이러한 방식으로 웹 추적이 가능해지며, 광고주는 이를 통해 광고 서버를 이용하여 각 사용자에게 관련 광고를 제공할 수 있다. 2014년 기준으로 일부 웹사이트는 100개 이상의 서드 파티 도메인에서 읽을 수 있는 쿠키를 설정하고 있었으며, 평균적으로 단일 웹사이트는 10개의 쿠키를 설정했다.[64][65]
트래킹 쿠키는 사용자의 액세스 기록을 추적한다는 의미에서, 또는 메인 HTML이 아닌 이미지 제공자가 설정한다는 의미에서 서드 파티 쿠키라고도 불린다. 행동 타겟팅 광고, 콘텐츠 연동형 광고, 검색 연동형 광고 등에 활용되며, 때로는 필터 버블의 원인이 되기도 한다.
이러한 쿠키 설정 방식은 개인 정보 침해 논란을 일으키기도 한다. 쿠키를 원치 않는 사용자를 위해 클라이언트용 보안 대책 소프트웨어는 트래킹 쿠키를 감지하고 제거하는 기능을 갖추고 있다.[117][118]
대부분의 최신 웹 브라우저는 개인 정보 설정에서 광고 차단기를 통해 서드 파티 쿠키를 차단하는 기능을 제공한다. 2020년부터 Apple Safari,[66] Firefox,[67] Brave[68]는 기본적으로 모든 서드 파티 쿠키를 차단하고 있다. Safari는 임베디드 사이트에서 Storage Access API를 사용하여 퍼스트 파티 쿠키를 설정할 권한을 요청할 수 있도록 한다. 2020년 5월, 구글 크롬 83은 시크릿 모드에서 서드 파티 쿠키를 기본적으로 차단하는 기능을 도입했으며, 일반 브라우징 중 차단은 선택 사항이다.[69] 2024년 4월, 크롬은 서드 파티 쿠키 차단을 기본적으로 2025년으로 연기했다.[70]
3. 7. 슈퍼쿠키 (Supercookie)
'''슈퍼쿠키'''는 최상위 도메인(예: `.com`) 또는 공용 접미사 (예: `.co.uk`)를 기원으로 하는 쿠키이다. 일반 쿠키는 `example.com`과 같은 특정 도메인 이름을 기원으로 한다.슈퍼쿠키는 잠재적인 보안 문제일 수 있으므로 웹 브라우저에서 차단되는 경우가 많다. 브라우저에서 차단되지 않은 경우, 악성 웹사이트를 제어하는 공격자는 슈퍼쿠키를 설정하여 악성 웹사이트와 동일한 최상위 도메인 또는 공용 접미사를 공유하는 다른 웹사이트에 대한 정당한 사용자 요청을 방해하거나 사칭할 수 있다. 예를 들어, `.com`을 기원으로 하는 슈퍼쿠키는 쿠키가 `example.com`에서 생성되지 않았더라도 `example.com`에 대한 요청에 악의적으로 영향을 미칠 수 있다. 이는 로그인을 위조하거나 사용자 정보를 변경하는 데 사용될 수 있다.[36]
공용 접미사 목록은 슈퍼쿠키가 제기하는 위험을 완화하는 데 도움이 된다. 공용 접미사 목록은 정확하고 최신 도메인 이름 접미사 목록을 제공하는 것을 목표로 하는 여러 벤더 간의 협력이다. 이전 버전의 브라우저에는 최신 목록이 없을 수 있으므로 특정 도메인의 슈퍼쿠키에 취약할 수 있다.[36]
"슈퍼쿠키"라는 용어는 HTTP 쿠키에 의존하지 않는 추적 기술에 사용되기도 한다. 2011년 8월, 마이크로소프트 웹사이트에서 두 가지 "슈퍼쿠키" 메커니즘이 발견되었다. 하나는 MUID(머신 고유 식별자) 쿠키를 재생성하는 쿠키 동기화였고, 다른 하나는 ETag 쿠키였다.[37] 언론의 주목을 받으면서 마이크로소프트는 나중에 이 코드를 비활성화했다.[38] 2021년 블로그 게시물에서 모질라는 브라우저 캐시 사용을 사이트 간 사용자 추적 수단으로 지칭하기 위해 "슈퍼쿠키"라는 용어를 사용했다.[39]
웹사이트 제작자는 쿠키를 사용하지 않고도, 서드 파티의 구글 애널리틱스 등을 이용하여 IP 주소, 사용자 에이전트, 웹 비콘, HTTP 리퍼러 등을 활용해 액세스 분석을 수행하여 Web tracking|웹 트래킹영어을 할 수 있다.
또한 Adobe Flash에서 사용되는 Local Shared Object (플래시 쿠키라고도 불림)나 Silverlight의 저장 영역, HTML5 (설치된 웹 폰트 등), Favicon 등을 이용하여 쿠키와 유사한 트래킹이 가능하다. 사용자는 이를 인지하기 매우 어려울 뿐만 아니라, 쿠키가 거부되거나 삭제되어도 이러한 정보를 통해 쉽게 생성 및 복원할 수 있다. 이러한 기술을 통틀어 Zombie cookie|좀비 쿠키영어 또는 Supercookie|슈퍼 쿠키영어라고 한다.[119]
문제가 되기 시작한 2011년 현재, 일반적인 웹 브라우저 및 보안 소프트웨어는 이에 대응하지 못하고 있으며, 이를 방지하거나 제거하기 위해서는 서드 파티 브라우저 애드온의 사용과 자바스크립트 제어 및 비활성화, 웹 브라우저의 개인 정보 보호 모드 또는 CCleaner를 이용한 캐시 및 열람 기록의 완전한 삭제 등의 조치가 필요하다. Tor 브라우저 및 Onion 브라우저는 현재 웹 트래킹 및 캔버스 핑거프린팅 등을 회피하는 데 유효하다.[120]
3. 8. 좀비 쿠키 (Zombie cookie)
좀비 쿠키는 웹 서버가 방문자의 컴퓨터 또는 다른 장치에, 방문자의 웹 브라우저 전용 쿠키 저장 위치 외부의 숨겨진 위치에 배치한 데이터 및 코드로, 원래 쿠키가 삭제된 후 일반 쿠키(HTTP 쿠키)를 자동으로 다시 생성한다. 좀비 쿠키는 플래시 로컬 공유 객체(Flash Local shared object), 웹 스토리지(HTML5 Web storage) 및 기타 클라이언트 측, 심지어 서버 측 위치와 같은 여러 위치에 저장될 수 있으며, 한 위치에서 부재가 감지되면 다른 위치에 저장된 데이터를 사용하여 JavaScript 코드가 누락된 인스턴스를 다시 생성한다.[40][41]Adobe Flash에서 사용되는 Local Shared Object (플래시 쿠키라고도 불림), Silverlight의 저장 영역, HTML5 (설치된 웹 폰트 등), Favicon 등을 이용하여 쿠키와 유사한 트래킹이 가능하다. 사용자는 이를 인지하기 매우 어려울 뿐만 아니라, 쿠키가 거부되거나 삭제되어도 이러한 정보를 통해 쉽게 생성 및 복원할 수 있다. 이러한 기술을 통틀어 Zombie cookie|좀비 쿠키영어 또는 Supercookie|슈퍼 쿠키영어라고 한다.[119]
2011년부터 문제가 되기 시작했으며, 일반적인 웹 브라우저 및 보안 소프트웨어는 이에 대응하지 못하고 있다. 이를 방지하거나 제거하기 위해서는 서드 파티 브라우저 애드온의 사용, 자바스크립트 제어 및 비활성화, 웹 브라우저의 개인 정보 보호 모드 또는 CCleaner를 이용한 캐시 및 열람 기록의 완전한 삭제 등의 조치가 필요하다. Tor 브라우저 및 Onion 브라우저는 현재 웹 트래킹 및 캔버스 핑거프린팅 등을 회피하는 데 유효하다.[120]
4. 쿠키의 구조 및 구현
HTTP는 원래 하이퍼텍스트에서 파일 전송을 위해 개발되었기 때문에, 동일한 URL에 대한 접근은 동일한 정보원[107]을 제공하는 것을 전제로 하는 상태 비저장 프로토콜이다.
월드 와이드 웹이 널리 퍼지면서, 상황에 따라 다른 내용의 페이지를 제공하고 싶다는[108] 요구가 생겨났다. 1994년 넷스케이프 커뮤니케이션즈는 이러한 요구를 충족시키기 위해 쿠키[109]를 제안하고 구현했다. 쿠키는 서버와 클라이언트 간의 상태를 관리하며, 다음과 같은 방식으로 작동한다.
# 웹 서버는 웹 브라우저에 상태를 구별하는 식별자를 HTTP 헤더에 포함하여 전달한다.
# 브라우저는 다음에 해당 서버와 통신할 때, 부여받은 식별자를 HTTP 헤더에 포함하여 전송한다.
# 서버는 해당 식별자를 기반으로 콘텐츠 내용을 사용자에게 맞춰 브라우저에 전달하며, 필요하면 새로운 식별자를 HTTP 헤더에 포함한다.
이후 2, 3의 과정을 반복한다. 이 메커니즘을 통해 상태 비저장 프로토콜인 HTTP 상에서 상태 저장 서비스를 실현한다. 설정된 쿠키는 조건을 만족하는 한, 몇 번이라도 요청에 포함되며, HTML 페이지 요청뿐만 아니라 이미지를 포함한 모든 요청이 대상이 된다.
"쿠키"라는 용어는 웹 브라우저 프로그래머 루 몬툴리가 매직 쿠키라는 용어에서 착안하여 만들었다.[125][126] 1994년 당시 넷스케이프 커뮤니케이션스의 직원이던 루 몬툴리는 MCI를 위한 전자 상거래 애플리케이션을 개발하면서 빈트 서프, 존 클렌신과의 기술 토론에서 쿠키를 제안했다. MCI는 서버가 트랜잭션 상태를 보유하는 것을 원치 않았고, 넷스케이프에게 사용자 컴퓨터에 상태를 저장하는 방법을 요청했다. 쿠키는 가상 쇼핑 카트 구현 문제에 대한 해결책을 제공했다.[128][129]
이후 쿠키는 1997년에 에서 처음 표준화되었으며, 2000년의 , 2011년의 에서 갱신되었다. 2007년 현재 대부분의 웹 서버와 웹 브라우저에서 사용 가능하다.
4. 1. 구조
쿠키는 이름, 값, 그리고 0개 이상의 속성 (이름/값 쌍)으로 구성된다.[130][131] 속성은 쿠키의 만료 기간, 도메인, 플래그 (예:Secure
및 HttpOnly
) 등의 정보를 저장한다.4. 2. 쿠키 설정
쿠키는 웹 서버가 `Set-Cookie` HTTP 헤더를 사용하여 설정하며, 이는 웹 서버의 HTTP 응답을 통해 전송된다. 이 헤더는 웹 브라우저가 쿠키를 저장하고 이후 서버 요청 시 전송할지를 지시한다. (브라우저가 쿠키를 지원하지 않거나 비활성화되어 있으면 이 헤더를 무시한다.)예를 들어, 브라우저가 `www.example.org` 웹사이트 홈페이지에 최초 요청을 보내면:
GET /index.html HTTP/1.1
Host: www.example.org
...
서버는 2개의 `Set-Cookie` 헤더와 함께 응답한다:
HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: theme=light
Set-Cookie: sessionToken=abc123; Expires=Wed, 09 Jun 2021 10:18:14 GMT
...
서버의 HTTP 응답에는 웹사이트 홈페이지 내용이 포함된다. 그러나 브라우저에 두 개의 쿠키를 설정하도록 지시한다. 첫 번째 `theme`은 `Expires` 또는 `Max-Age` 속성이 없으므로 세션 쿠키로 간주되어 브라우저가 닫힐 때 삭제된다. 두 번째 `sessionToken`은 `Expires` 속성을 포함하여 특정 날짜와 시간에 삭제되는 영구 쿠키이다.
그 다음 브라우저가 웹사이트에서 `spec.html` 페이지를 요청하면, 서버가 설정한 두 쿠키를 담은 `Cookie` HTTP 헤더를 포함한다:
GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123
…
이 방식으로 서버는 이 요청이 이전 요청과 관련이 있음을 인지한다. 서버는 요청된 페이지를 보내면서 새 쿠키를 추가, 수정, 삭제하기 위해 `Set-Cookie` 헤더를 더 포함할 수 있다.
쿠키 값은 페이지 요청에 응답하여 `Set-Cookie` 헤더를 포함함으로써 서버에 의해 수정될 수 있다. 브라우저는 이후 오래된 값을 새로운 값으로 대체한다.
쿠키의 값은 `,`와 `;`, 공백 문자를 제외한 인쇄 가능한 모든 ASCII 문자(`!`에서 `~`까지, 유니코드 `\u0021`에서 `\u007E`까지)로 구성될 수 있다. 쿠키의 이름은 `=` 및 동일 문자를 제외하는데, 그 이유는 이름과 값 사이를 구별하는 구분자 역할을 하기 때문이다.[134]
쿠키는 브라우저 내에서 실행되는 자바스크립트와 같은 스크립트 언어에 의해서도 설정될 수 있다. 자바스크립트에서 `document.cookie` 객체가 이 목적을 위해 사용된다. 예를 들어, `document.cookie = "temperature=20"`는 `temperature`라는 쿠키 이름과 값 `20`을 만든다.[135]
4. 3. 쿠키 속성
쿠키는 이름, 값, 그리고 여러 속성으로 구성된다.[130][131] 이러한 속성은 쿠키의 만료 기간, 도메인, 플래그 (예: `Secure` 및 `HttpOnly`) 등의 정보를 담고 있다.서버는 `Set-Cookie` HTTP 헤더를 사용하여 쿠키를 설정하며, 이는 웹 서버의 HTTP 응답을 통해 브라우저에 전달된다. 브라우저는 이 지시에 따라 쿠키를 저장하고, 이후 서버에 요청을 보낼 때 해당 쿠키를 함께 전송한다. (브라우저에서 쿠키를 지원하지 않거나 비활성화한 경우에는 이 헤더를 무시한다.)
쿠키 값은 쉼표(`,`), 세미콜론(`;`), 공백 문자를 제외한 모든 인쇄 가능한 ASCII 문자 (`!`에서 `~`까지, 유니코드 `\u0021`에서 `\u007E`까지)로 구성될 수 있다. 쿠키 이름은 `=`과 동일한 문자를 제외하는데, 이는 이름과 값을 구분하는 역할을 하기 때문이다.
쿠키는 브라우저에서 실행되는 자바스크립트와 같은 스크립트 언어를 통해서도 설정할 수 있다. 자바스크립트에서는 `document.cookie` 객체를 사용하여 쿠키를 생성한다. (예: `document.cookie = "temperature=20"`).[135]
브라우저는 서버로 요청을 보낼 때 쿠키 속성을 포함하지 않고, 쿠키의 이름과 값만 보낸다. 쿠키 속성은 브라우저가 쿠키를 삭제하거나, 차단하거나, 서버에 보낼 시점을 결정하는 데 사용된다.
- `Domain` 및 `Path` 속성: 쿠키의 범위를 정의한다. 즉, 어떤 웹사이트에서 쿠키를 사용할 수 있는지 지정한다.
- 보안상의 이유로 쿠키는 현재 리소스의 최상위 도메인 및 하위 도메인에서만 설정할 수 있으며, 다른 도메인 및 하위 도메인에서는 설정할 수 없다. (예: `example.org`는 `foo.com` 도메인의 쿠키를 설정할 수 없다.)
- 서버에서 `Domain` 및 `Path` 속성을 지정하지 않으면, 요청된 리소스의 도메인 및 경로로 기본 설정된다.[50]
- 대부분의 브라우저에서 도메인 없이 `foo.com`에서 설정된 쿠키와 `foo.com` 도메인으로 설정된 쿠키는 다르게 처리된다. 전자는 `foo.com`에 대한 요청에만 전송되는 '호스트 전용 쿠키'이고, 후자는 모든 하위 도메인(`docs.foo.com` 등)에도 전송된다.[51][52] (Windows 10 RS3 이전의 Edge, IE 11 및 Windows 10 RS4 (2018년 4월) 이전의 Internet Explorer는 예외적으로 항상 하위 도메인으로 쿠키를 전송한다.[53])
- `Expires` 속성: 브라우저가 쿠키를 삭제해야 하는 특정 날짜와 시간을 `Wdy, DD Mon YYYY HH:MM:SS GMT` 형식 (또는 YY 값이 0 이상이고 69 이하인 경우 `Wdy, DD Mon YY HH:MM:SS GMT` 형식)으로 지정한다.[55]
- `Max-Age` 속성: 쿠키 만료 시간을 브라우저가 쿠키를 받은 시간으로부터의 미래의 초 단위 간격으로 설정한다. (인터넷 익스플로러는 `Max-Age`를 지원하지 않았다.[56][57])
- `Secure` 속성: 쿠키 통신을 암호화된 전송으로 제한하여, 브라우저가 보안/암호화된 연결을 통해서만 쿠키를 사용하도록 지시한다.
- 보안을 위해 `Secure` 속성이 있는 쿠키는 보안 연결을 통해서만 설정해야 한다.
- `HttpOnly` 속성: 브라우저가 HTTP (및 HTTPS) 요청 이외의 채널을 통해 쿠키를 노출하지 않도록 지시한다. 즉, 자바스크립트와 같은 클라이언트 측 스크립팅 언어를 통해 쿠키에 접근할 수 없으므로, 크로스 사이트 스크립팅을 통한 쿠키 탈취를 방지할 수 있다.[58]
쿠키는 HTML DOM의 일부로 접근할 수 있으며, 자바스크립트를 비롯한 클라이언트 측 스크립트에서 쿠키를 조작할 수 있다. 단, 쿠키에는 유효 범위가 설정되어 있어 해당 URL에서 유효한 쿠키만 접근할 수 있다.
쿠키를 설정할 때 어떤 요청에 대해 쿠키 정보를 다시 보낼지 URL 범위를 지정한다. 기본값은 쿠키를 설정한 서버에 대한 모든 요청이며, 범위를 넓히거나 좁힐 수 있다. 하지만 범위를 넓히더라도 최상위 도메인보다는 좁은 범위여야 한다.
쿠키의 유효 기간은 보통 브라우저를 종료할 때까지이지만, 지정된 기한까지는 브라우저를 다시 시작해도 유지되도록 설정할 수 있다. 유효 기간 정보도 서버에서 브라우저로 쿠키 정보를 전송하는 단계에서 추가된다. 무기한 설정은 불가능하며, 2038년 문제로 인해 2038년 1월 19일 3시 14분 07초(UTC) 이후의 시간을 기한으로 설정하는 경우는 드물다.[115]
4. 4. 구현 요건
RFC 표준[132][133]에 따르면, 웹 브라우저는 쿠키 지원을 위해 다음 요건을 충족해야 한다.- 40,960억 크기의 쿠키를 지원해야 한다.
- 한 도메인 당 최소 50개의 쿠키를 지원해야 한다. (예: 각 웹사이트 당)
- 총 최소 3,000개의 쿠키를 지원해야 한다.
5. 쿠키의 활용
HTTP 쿠키는 웹사이트 이용 시 편의성을 높이고 맞춤형 서비스를 제공하기 위해 다양하게 활용된다.
쿠키는 주로 웹사이트 세션 관리에 사용된다. 쇼핑몰의 장바구니 기능이나 로그인 상태 유지가 대표적인 예시이다. 사용자가 장바구니에 상품을 담거나 로그인하면, 서버는 해당 사용자에게 고유한 세션 ID를 쿠키 형태로 발급한다. 이후 사용자가 웹사이트를 탐색할 때마다 브라우저는 이 쿠키를 서버에 전송하고, 서버는 세션 ID를 통해 사용자를 식별하여 장바구니 정보나 로그인 상태를 유지한다.
또한, 쿠키는 개인화된 서비스를 제공하는 데에도 활용된다. 사용자가 웹사이트에서 특정 설정을 선택하면(예: 검색 결과 표시 개수, 웹 페이지 색상), 서버는 이러한 설정을 쿠키에 저장한다. 이후 사용자가 다시 웹사이트를 방문하면, 서버는 쿠키에 저장된 설정을 불러와 사용자에게 맞춤형 화면을 보여준다. 구글 검색 엔진이나 덕덕고 검색 엔진이 이러한 방식으로 쿠키를 활용한다.[132][133]
쿠키는 사용자의 웹 이용 행태를 추적하는 데에도 사용될 수 있다. 사용자가 특정 웹사이트를 방문하면, 서버는 사용자에게 고유한 식별자를 쿠키 형태로 발급하고, 사용자가 웹사이트를 탐색하는 동안 방문한 페이지, 시간 등의 정보를 기록한다. 이러한 정보는 사용자의 관심사를 파악하고 맞춤형 광고를 제공하는 데 활용될 수 있다. 하지만, 이러한 트래킹 쿠키는 개인 정보 침해 논란을 일으키기도 한다.
미디어위키와 같은 소프트웨어에서도 쿠키를 사용하여 로그인 정보를 관리한다. 사용자가 로그인하면 서버는 사용자 이름과 비밀번호를 확인하고 (암호화된) 로그인 정보를 쿠키로 전송한다. 이후 사용자가 페이지를 열람할 때마다 브라우저는 쿠키를 전송하고, 서버는 쿠키 정보를 기반으로 사용자에게 맞춤화된 페이지를 제공한다.
5. 1. 세션 관리
HTTP는 원래 하이퍼텍스트에서 파일 전송을 위해 개발되었기 때문에, 동일한 URL에 대한 접근은 상황에 관계없이 동일한 정보를 제공하는 것을 전제로 한다.[107] 즉, HTTP는 같은 순간에 같은 내용의 요청을 하면, 이전 통신과 관계없이 구별되지 않는 상태 비저장 프로토콜이다.월드 와이드 웹이 널리 퍼지면서 상황에 따라 다른 내용의 페이지를 제공하고 싶다는 요구가 생겨났다.[108] HTTP만으로는 이러한 요구를 충족하기 어려웠고, IP 주소로 구별하거나 고유한 URL을 생성하는 등의 방법은 여러 단점을 가지고 있었다.
1994년, 넷스케이프 커뮤니케이션즈는 이러한 문제를 해결하기 위해 쿠키[109]를 제안하고 구현했다. 쿠키는 서버와 클라이언트 간의 상태를 관리하는 다음과 같은 메커니즘을 제공한다.
# 웹 서버는 웹 브라우저에 상태를 구별하는 식별자를 HTTP 헤더에 포함하여 전달한다.
# 브라우저는 다음에 해당 서버와 통신할 때, 부여받은 식별자를 HTTP 헤더에 포함하여 전송한다.
# 서버는 해당 식별자를 기반으로 사용자에게 맞춰 내용을 커스터마이징하여 브라우저에 전달하고, 필요하면 새로운 식별자를 HTTP 헤더에 포함한다.
# 이후 2, 3의 과정을 반복한다.
이 메커니즘을 통해 상태 비저장 프로토콜인 HTTP 상에서 상태 저장 서비스를 실현한다. 한번 설정된 쿠키는 조건을 만족하는 한, 몇 번이라도 요청에 포함되며, HTML 페이지뿐만 아니라 이미지를 포함한 모든 요청이 대상이 된다.
이후 쿠키는 1997년에 에서 처음 표준화되었으며, 2000년의 , 2011년의 에서 갱신되었다. 2007년 현재 대부분의 웹 서버와 웹 브라우저에서 사용 가능하다.
쿠키는 주로 쇼핑 사이트에서 장바구니나 로그인 상태를 관리하는 데 사용된다. 또한 IP 주소에 의존하지 않고 클라이언트를 식별할 수 있게 하여, 웹 사이트 운영자나 인터넷 광고 배포업자 등이 사용자의 상세한 접속 기록을 얻는 데에도 사용된다.
쿠키는 매번 전송되며, HTTP 헤더의 일부이므로 ASCII 문자열이어야 한다. 따라서 쿠키로 데이터를 직접 처리하기보다는 세션 ID(Session ID)를 구현하는 수단으로 사용하는 경우가 많다. 이 경우 실제 데이터는 세션 ID를 키로 하여 서버가 보관하게 된다.
예를 들어, 특정 페이지의 표시 횟수를 웹 페이지에 표시하는 과정은 다음과 같다.
# 브라우저가 서버에 열람을 요청한다. (쿠키 정보 없음)
# 서버는 브라우저에 "1"회라는 쿠키 정보와 "1회"로 표시하는 데이터를 전송한다.
# 브라우저가 서버에 열람을 요청하며, "1"의 쿠키 정보를 서버에 전송한다.
# 서버는 "1"이라는 쿠키 정보에 근거하여 브라우저에 "2"회라는 쿠키 정보와 "2회"로 표시하는 데이터를 전송한다.
미디어위키에서도 로그인 정보를 쿠키로 구현하고 있다.
# 로그인 페이지에서 사용자 이름과 비밀번호를 서버로 전송한다. (쿠키 미사용)
# 서버는 사용자 이름과 비밀번호를 확인하고, "로그인 성공" 페이지와 함께 사용자 이름과 비밀번호를 (암호화하여) 쿠키로 전송한다.
# 다음 열람부터는 브라우저가 페이지 열람 요청과 함께 쿠키를 전송하고, 서버는 쿠키 정보에 따라 사용자에게 맞춤화된 페이지를 전송한다.
# 로그아웃을 클릭하면 "로그아웃" 페이지와 함께 빈 쿠키 정보를 전송하여, 브라우저는 기존 쿠키 정보를 빈 쿠키 정보로 덮어쓴다.
쿠키는 임의의 데이터 조각으로, 웹 브라우저에 의해 선택되어 처음 전송되며 클라이언트 컴퓨터에 저장된다. 이후 브라우저는 모든 요청을 서버로 되돌려 보내면서 상태(이전 이벤트)를 무상태 HTTP 트랜잭션으로 유입시킨다. 쿠키가 없으면 웹 페이지의 각 검색 또는 구성 요소는 사용자가 만드는 다른 모든 페이지와 무관한 별개의 이벤트로 취급된다. 쿠키는 일반적으로 웹 서버에 의해 설정되지만, 자바스크립트와 같은 스크립트 언어를 사용하여 클라이언트에 의해 설정될 수도 있다. (단, HttpOnly 플래그가 설정되지 않은 경우)
쿠키 사양[132][133]은 브라우저가 다음 요건을 충족할 것을 명시한다.
요건 |
---|
4,096바이트 크기의 쿠키를 지원할 것 |
한 도메인 당 최소 50개 쿠키를 지원할 것 (각 웹사이트 당) |
총 최소 3,000개 쿠키를 지원할 것 |
쿠키는 원래 사용자가 웹사이트를 탐색하면서 구매하려는 항목을 기록하는 기능을 제공하기 위해 도입되었다 ('가상 쇼핑 카트' 또는 '쇼핑 바구니').[9][10] 오늘날에는 사용자의 쇼핑 카트 내용은 클라이언트의 쿠키가 아닌 서버의 데이터베이스에 저장되는 경우가 많다. 서버는 어떤 사용자가 어떤 쇼핑 카트에 할당되었는지 추적하기 위해 고유 세션 식별자(일반적으로 임의의 문자와 숫자로 구성된 긴 문자열)가 포함된 쿠키를 클라이언트에 보낸다. 쿠키는 클라이언트가 요청할 때마다 서버로 전송되므로, 해당 세션 식별자는 사용자가 웹사이트의 새 페이지를 방문할 때마다 서버로 다시 전송되어 서버가 사용자에게 어떤 쇼핑 카트를 표시해야 하는지 알 수 있게 한다.
쿠키의 또 다른 일반적인 사용 사례는 웹사이트 로그인이다. 사용자가 웹사이트의 로그인 페이지를 방문하면 웹 서버는 일반적으로 고유 세션 식별자가 포함된 쿠키를 클라이언트에 보낸다. 사용자가 성공적으로 로그인하면 서버는 해당 특정 세션 식별자가 인증되었음을 기억하고 사용자에게 해당 서비스에 대한 액세스 권한을 부여한다.
세션 쿠키는 고유한 세션 식별자만 포함하므로 웹사이트가 각 사용자에 대해 저장할 수 있는 개인 정보의 양은 사실상 무제한이다. 웹사이트는 쿠키 크기에 대한 제한을 받지 않는다. 또한 세션 쿠키는 정보량이 적고 대역폭을 많이 필요로 하지 않으므로 페이지 로드 시간을 개선하는 데 도움이 된다.
5. 2. 개인화
많은 웹사이트에서 사용자의 선호도에 따른 개인화를 위해 쿠키를 사용한다. 사용자는 웹 양식에 선호도를 입력하고 해당 양식을 서버에 제출하여 선호도를 선택한다. 서버는 선호도를 쿠키에 인코딩하여 브라우저로 쿠키를 보낸다. 이러한 방식으로 사용자가 웹사이트의 페이지에 접근할 때마다 서버는 사용자의 선호도에 따라 페이지를 개인화할 수 있다. 예를 들어, 구글(Google) 검색 엔진은 한때 쿠키를 사용하여 사용자가 (등록하지 않은 사용자라도) 페이지당 표시할 검색 결과 수를 결정할 수 있도록 했다.[132][133]또한, 덕덕고(DuckDuckGo)는 사용자가 웹 페이지의 색상과 같은 보기 기본 설정을 설정할 수 있도록 쿠키를 사용한다.[132][133]
5. 3. 웹 추적 (Tracking)
트래킹 쿠키는 사용자가 웹을 돌아다니는 습관을 추적하는 데 사용된다. IP 주소나 referer 필드를 사용해서도 어느 정도는 추적이 가능하지만, 쿠키를 사용하면 훨씬 더 정확하게 추적할 수 있다. 작동 방식은 다음과 같다.[45]# 사용자가 어떤 사이트에 처음 방문하면 (쿠키가 없는 상태), 서버는 사용자가 처음 왔다고 판단한다. 그래서 서버는 특별한 식별자 (주로 임의의 문자와 숫자로 만들어진 문자열)를 만들어서 사용자가 요청한 페이지와 함께 쿠키 형태로 브라우저에 보낸다.
# 이제부터 사용자가 그 사이트에서 다른 페이지를 요청할 때마다, 브라우저는 자동으로 쿠키를 서버에 함께 보낸다. 서버는 페이지를 보내주는 것뿐만 아니라, 요청된 페이지 주소(URL), 요청 시간, 쿠키 등의 정보를 로그 파일에 기록한다.
이렇게 기록된 로그 파일을 분석하면, 사용자가 어떤 페이지들을 어떤 순서로, 얼마나 오랫동안 봤는지 알 수 있게 된다.
기업들은 이러한 트래킹 쿠키를 이용해서 사용자의 웹 사용 습관을 파악하고, 구매 습관에 대한 정보를 수집한다.[45] ''월스트리트 저널''의 조사에 따르면, 미국의 50대 웹사이트들은 평균적으로 64개의 트래킹 기술을 사용자 컴퓨터에 설치했고, 총 3,180개의 트래킹 파일이 만들어졌다고 한다. 이렇게 모인 정보는 입찰에 참여하는 기업들에게 팔릴 수 있다.
쿠키는 원래 하이퍼텍스트에서 단순 파일 전송을 위해 개발된 HTTP에서, 상황에 맞는 페이지를 제공하기 위해 만들어졌다. HTTP는 원래 상태가 없는 프로토콜이기 때문에, 누가 이전에 무엇을 했는지 기억하지 못한다. 이러한 한계를 극복하기 위해 IP 주소를 사용하거나 특별한 URL을 만들 수도 있지만, 여러 문제점들이 있었다.
그래서 1994년에 넷스케이프 커뮤니케이션즈에서 쿠키를 제안하고 구현했다. 쿠키는 다음과 같이 작동한다.[109]
# 웹 서버는 웹 브라우저에게 특별한 식별자를 HTTP 헤더에 넣어서 보낸다.
# 브라우저는 다음에 그 서버와 통신할 때, 받은 식별자를 HTTP 헤더에 넣어서 보낸다.
# 서버는 그 식별자를 보고 사용자에게 맞는 내용을 브라우저에 보내준다. 필요하면 새로운 식별자를 보낼 수도 있다.
#: 이후 2, 3번 과정이 반복된다.
이러한 방식을 통해, 상태가 없는 HTTP에서도 상태를 기억하는 서비스를 만들 수 있게 되었다. 한번 설정된 쿠키는 조건을 만족하면 계속해서 요청에 포함된다. HTML 페이지뿐만 아니라 이미지 등 모든 요청이 대상이 된다.
쿠키는 1997년에 IETF RFC 2109에서 처음 표준화되었고, 2000년(IETF RFC 2965)과 2011년(IETF RFC 6265)에 업데이트되었다. 2007년 기준으로 대부분의 웹 서버와 웹 브라우저에서 사용할 수 있다.
쿠키는 쇼핑 사이트에서 장바구니나 로그인 상태를 유지하는 데 주로 사용된다. 또한, 웹 사이트 운영자나 인터넷 광고업자들이 사용자의 접속 기록을 자세히 파악하는 데에도 사용된다.
쿠키는 매번 전송되고, HTTP 헤더의 일부이기 때문에 ASCII 문자열 형태여야 한다. 그래서 쿠키 자체에 데이터를 직접 저장하기보다는, 세션 ID를 구현하는 방식으로 사용되는 경우가 많다. 이 경우 실제 데이터는 세션 ID를 열쇠로 해서 서버에 보관된다.
쿠키를 이용하면 사용자의 다른 요청들을 연결할 수 있다.
이러한 기법은 구글 애드센스 같은 애드 네트워크를 이용하는 웹 광고 업자들이 자주 사용한다. 인터넷 광고에서 배너 광고는 보통 광고 회사 서버(서드 파티)에서 이미지를 가져오는 방식이다. 쿠키는 HTML뿐만 아니라 이미지에도 설정될 수 있다. HTTP에서는 링크를 타고 온 원래 페이지 주소도 함께 보내기 때문에, 광고 회사는 여러 사이트에서 사용자의 방문 기록을 파악할 수 있다. (자세한 내용은 쿠키와 스파이웨어의 관계 참고) 사용자의 접속 기록을 추적한다는 의미에서 트래킹 쿠키, 또는 HTML이 아닌 이미지 제공자가 설정한다는 의미에서 서드 파티 쿠키라고 불리기도 한다. 이러한 쿠키들은 행동 타겟팅 광고, 콘텐츠 연동형 광고, 검색 연동형 광고 등에 사용되고, 필터 버블의 원인이 되기도 한다. 최근에는 Federated Learning of Cohorts로 전환하려는 움직임도 있다.
이러한 트래킹 쿠키가 개인 정보를 침해한다고 생각하는 사람도 있고, 그렇지 않은 사람도 있다. 이러한 쿠키를 원하지 않는 사용자를 위해, 대부분의 보안 소프트웨어는 트래킹 쿠키를 찾아내고 제거하는 기능을 가지고 있다.[117][118] 하지만 모든 사용자가 이러한 기능을 제대로 이해하고 있다고 보기는 어렵고, 컴퓨터 바이러스로 오해해서 초보자들이 놀라는 경우도 종종 있다.
웹사이트 제작자는 쿠키를 사용하지 않고도 서드 파티의 구글 애널리틱스 등을 이용해서 IP 주소, 사용자 에이전트, 웹 비콘, HTTP 리퍼러 등으로 웹 트래킹을 할 수 있다. 자바스크립트나 HTML5 (WebGL, 캔버스 요소, 웹 폰트 등)를 이용한 다른 기술들에 대해서는 핑거프린트 문서를 참고하면 된다.
Adobe Flash에서 사용되는 Local Shared Object (플래시 쿠키), Silverlight 저장 영역, HTML5 (설치된 웹 폰트 등), Favicon 등을 통해서도 쿠키와 비슷한 추적이 가능하다. 사용자는 이러한 기술들을 알아차리기 어렵고, 쿠키가 삭제되어도 이러한 정보들을 통해 쉽게 복원될 수 있다. 이러한 기술들을 통틀어 Zombie cookie영어 (좀비 쿠키) 또는 Supercookie영어 (슈퍼 쿠키)라고 부른다.[119]
2011년부터 문제가 되기 시작했는데, 일반적인 웹 브라우저나 보안 소프트웨어는 이러한 기술에 대응하지 못하고 있다. 이를 막거나 제거하려면, 서드 파티 브라우저 애드온을 사용하거나, 자바스크립트를 제어 또는 비활성화하거나, 웹 브라우저의 개인 정보 보호 모드를 사용하거나, CCleaner를 이용해서 캐시와 열람 기록을 완전히 삭제해야 한다. Tor 브라우저나 Onion 브라우저는 현재 웹 트래킹과 캔버스 핑거프린팅 등을 피하는 데 효과적이다.[120]
6. 쿠키의 대안 기술
HTTP 쿠키는 유명한 구운 간식과 같은 이름을 공유한다.() 쿠키를 이용해 수행할 수 있는 작업의 일부는 다른 메커니즘을 사용하여 수행할 수도 있다.
쿠키의 단점을 보완하거나 대체하기 위해 개발된 여러 기술들이 있다. 주요 기술들은 다음과 같다:
- 인증 및 세션 관리:
- JSON 웹 토큰(JWT): 사용자 신원 및 인증 정보를 저장하는 자체 포함 정보 패킷으로, 세션 쿠키 대신 사용될 수 있다. 다만, JWT는 웹 애플리케이션에서 각 HTTP 요청에 명시적으로 첨부해야 한다.
- 기본 액세스 인증 및 다이제스트 액세스 인증: HTTP 프로토콜에 포함된 인증 방식으로, 사용자가 올바른 사용자 이름과 비밀번호를 제공한 경우에만 웹 페이지 접근을 허용한다. 브라우저는 이러한 자격 증명을 저장하여 후속 페이지 요청마다 전송하며, 이는 사용자 추적에 사용될 수 있다.[1]
- URL의 쿼리 문자열 부분: 사용자 식별 및 상태 유지를 위해 사용될 수 있다. 자바 서블릿과 PHP 세션 메커니즘은 쿠키가 비활성화된 경우 이 방식을 사용한다. 하지만, 쿼리 문자열은 URL의 일부이므로, URL 재사용 시 동일한 정보가 전송되어 혼란을 야기할 수 있으며, 보안 취약점도 존재한다.[3][5]
- 숨겨진 필드가 있는 웹 폼: 세션 추적의 한 형태로, URL 쿼리 문자열 사용과 유사하다. HTTP POST로 처리될 경우 숨겨진 필드를 포함한 폼 정보가 HTTP 요청 본문에 전송되어 URL이나 쿠키의 일부가 아니게 된다. 이 방식은 추적 정보가 URL이 아닌 HTTP 요청 본문에 있어 사용자가 알아차리기 어렵고, URL 복사 시 세션 정보가 복사되지 않는다는 장점이 있다.[6][7]
- `window.name`: 모든 최신 웹 브라우저에서 지원하는 DOM 속성으로, 상당한 양의 데이터(2–32MB)를 JavaScript를 통해 저장할 수 있으며, 세션 쿠키 대신 사용될 수 있다. JSON/JavaScript 객체와 결합하여 클라이언트 측에 복잡한 세션 변수를 저장할 수 있다.[8]
- 웹 추적:
- IP 주소: 서버는 브라우저를 실행하는 컴퓨터의 IP 주소(또는 프록시)를 알 수 있으며, 이를 통해 사용자 세션을 연결할 수 있다. 그러나 NAT 환경에서는 여러 PC가 공용 IP를 공유하며, Tor와 같은 익명성 시스템에서는 IP 추적이 어렵다.
- ETag: 브라우저에 의해 캐시되고, 동일한 리소스에 대한 후속 요청과 함께 반환되므로 추적에 사용될 수 있다. ETag는 브라우저에서 브라우저 캐시를 지워 삭제할 수 있다.
- 브라우저 캐시: 개별 사용자 추적에 사용될 수 있는 정보를 저장할 수 있다. 웹 브라우저는 캐시에 리소스의 최신 버전이 있으면 웹사이트에서 다운로드하지 않고 캐시된 리소스를 사용한다.
- 브라우저 지문: 브라우저 버전, 화면 해상도, 운영 체제 등 브라우저 구성 정보를 수집하여 식별하는 기술이다. 쿠키가 없어도 개별 사용자 또는 장치를 식별할 수 있다.
- Local Shared Object (플래시 쿠키), Silverlight 저장 영역, HTML5, Favicon 등을 이용하여 쿠키와 유사한 트래킹이 가능하다. 이러한 기술은 Zombie cookie영어 (좀비 쿠키) 또는 Supercookie영어 (슈퍼 쿠키)라고 한다.[119]
- 웹 스토리지:
- 일부 웹 브라우저는 페이지가 정보를 로컬에 저장하여 나중에 사용할 수 있도록 하는 지속성 메커니즘을 지원한다.
- HTML5 표준(대부분의 최신 웹 브라우저가 어느 정도 지원)에는 로컬 스토리지와 세션 스토리지의 두 가지 유형의 스토리지를 허용하는 웹 스토리지라는 JavaScript API가 포함되어 있다.
- 인터넷 익스플로러는 브라우저의 기록, 브라우저의 즐겨찾기, XML 저장소("사용자 데이터") 또는 디스크에 저장된 웹 페이지 내에서 지속적인 정보를 지원한다.[105]
- 일부 웹 브라우저 플러그인에는 지속성 메커니즘도 포함되어 있다. 예를 들어, Adobe Flash에는 로컬 공유 객체가 있고 Microsoft Silverlight에는 격리된 스토리지가 있다.[106]
6. 1. 인증 및 세션 관리
JSON 웹 토큰(JWT)은 사용자 신원 및 인증 정보를 저장하는 데 사용되는 자체 포함 정보 패킷으로, 세션 쿠키 대신 사용될 수 있다. 쿠키와 달리 JWT는 웹 애플리케이션에서 각 HTTP 요청에 명시적으로 첨부해야 한다.HTTP 프로토콜에는 기본 액세스 인증 및 다이제스트 액세스 인증 프로토콜이 포함되어 있어, 사용자가 올바른 사용자 이름과 비밀번호를 제공한 경우에만 웹 페이지 접근을 허용한다. 브라우저는 이러한 자격 증명을 저장하여 후속 페이지 요청마다 전송하며, 이는 사용자 추적에 사용될 수 있다.[1]
URL의 쿼리 문자열 부분도 사용자 식별 및 상태 유지를 위해 사용될 수 있다. 자바 서블릿과 PHP 세션 메커니즘은 쿠키가 비활성화된 경우 이 방식을 사용한다. 웹 서버는 웹 페이지 내 모든 링크에 고유 세션 식별자를 포함하는 쿼리 문자열을 추가하고, 사용자가 링크를 따라가면 브라우저는 쿼리 문자열을 서버로 보내 사용자를 식별한다.[2]
쿼리 문자열은 쿠키와 유사하게 서버가 선택한 임의의 정보를 포함하고 요청 시마다 서버로 전송되지만, 몇 가지 차이점이 있다. 쿼리 문자열은 URL의 일부이므로, URL 재사용 시 동일한 정보가 전송되어 혼란을 야기할 수 있다. 예를 들어, 사용자의 기본 설정이 URL에 인코딩되어 있고 사용자가 이 URL을 이메일로 다른 사용자에게 보내면, 해당 설정이 다른 사용자에게도 적용된다.[3] 또한, 동일한 사용자가 서로 다른 소스에서 동일한 페이지에 접근하는 경우, 쿼리 문자열이 매번 동일하다는 보장이 없다.[4]
쿼리 문자열은 세션 고정 공격, 리퍼러 로깅 공격 등 보안 익스플로잇에 취약하다는 단점이 있다. 세션 식별자를 HTTP 쿠키로 전송하는 것이 더 안전하다.[5]
숨겨진 필드가 있는 웹 폼을 사용하는 것도 세션 추적의 한 형태이다. 이 기술은 URL 쿼리 문자열 사용과 유사하며, HTTP GET 메서드로 처리되는 경우 URL 쿼리 문자열과 유사하게 작동한다. 대부분의 폼은 HTTP POST로 처리되는데, 이 경우 숨겨진 필드를 포함한 폼 정보가 HTTP 요청 본문에 전송되어 URL이나 쿠키의 일부가 아니다.[6] 이 방식은 추적 정보가 URL이 아닌 HTTP 요청 본문에 있어 사용자가 알아차리기 어렵고, URL 복사 시 세션 정보가 복사되지 않는다는 장점이 있다.[7]
모든 최신 웹 브라우저는 DOM 속성 `window.name`을 사용하여 상당한 양의 데이터(2–32MB)를 JavaScript를 통해 저장할 수 있으며, 이는 세션 쿠키 대신 사용될 수 있다. JSON/JavaScript 객체와 결합하여 클라이언트 측에 복잡한 세션 변수를 저장할 수 있다.[8]
`window.name`은 모든 창 또는 탭이 처음 열릴 때 빈 속성을 가진다는 단점이 있지만,[9] 쿠키와 달리 모든 요청에 대해 서버로 자동 전송되지 않아 네트워크 쿠키 스니핑 공격에 취약하지 않다는 점에서 더 안전할 수 있다.[10]
6. 2. 웹 추적
IP 주소를 기반으로 사용자를 추적할 수 있다. 서버는 브라우저를 실행하는 컴퓨터의 IP 주소(또는 프록시)를 알 수 있으며, 이를 통해 사용자 세션을 연결할 수 있다. 그러나 NAT 환경에서는 여러 PC가 공용 IP를 공유하며, Tor와 같은 익명성 시스템에서는 IP 추적이 어렵다.ETag는 브라우저에 의해 캐시되고, 동일한 리소스에 대한 후속 요청과 함께 반환되므로 추적에 사용될 수 있다. 추적 서버는 브라우저에서 받은 ETag를 반복하여 영구적으로 유지되도록 할 수 있다. ETag는 브라우저에서 브라우저 캐시를 지워 삭제할 수 있다.
브라우저 캐시는 개별 사용자 추적에 사용될 수 있는 정보를 저장할 수 있다. 웹 브라우저는 캐시에 리소스의 최신 버전이 있으면 웹사이트에서 다운로드하지 않고 캐시된 리소스를 사용한다. 예를 들어, 웹사이트는 사용자 고유 식별자를 설정하는 코드가 포함된 JavaScript 파일을 제공할 수 있다. 사용자가 처음 방문한 후, 페이지에 액세스할 때마다 이 파일은 캐시에서 로드되므로 내용은 변경되지 않는다.
브라우저 지문은 브라우저 버전, 화면 해상도, 운영 체제 등 브라우저 구성 정보를 수집하여 식별하는 기술이다. 쿠키가 없어도 개별 사용자 또는 장치를 식별할 수 있다. 웹 분석 서비스는 클라이언트 측 스크립팅 언어를 사용하여 더 많은 정보를 수집하고, 이를 통합하여 장치 지문을 생성한다. 전자 프론티어 재단은 브라우저 지문에서 최소 18.1비트의 엔트로피가 가능하다고 측정했다.[103] 캔버스 지문은 5.7비트를 더 추가한다.
웹사이트 제작자는 쿠키 없이도 서드 파티의 구글 애널리틱스 등을 이용하여 IP 주소, 사용자 에이전트, 웹 비콘, HTTP 리퍼러 등으로 액세스 분석을 할 수 있다. 자바스크립트 및 HTML5 (WebGL, 캔버스 요소, 웹 폰트 등)를 활용한 다른 기술은 핑거프린트를 참조하라.
Local Shared Object (플래시 쿠키), Silverlight 저장 영역, HTML5, Favicon 등을 이용하여 쿠키와 유사한 트래킹이 가능하다. 사용자는 이를 인지하기 어렵고, 쿠키가 거부되거나 삭제되어도 쉽게 생성 및 복원될 수 있다. 이러한 기술을 Zombie cookie영어 (좀비 쿠키) 또는 Supercookie영어 (슈퍼 쿠키)라고 한다.[119]
2011년부터 문제가 되기 시작했지만, 일반적인 웹 브라우저 및 보안 소프트웨어는 대응하지 못하고 있다. 이를 방지하려면 서드 파티 브라우저 애드온, 자바스크립트 제어, 개인 정보 보호 모드, CCleaner를 이용한 캐시 및 열람 기록 삭제 등의 조치가 필요하다. Tor 브라우저 및 Onion 브라우저는 웹 트래킹 및 캔버스 핑거프린팅 회피에 유효하다.[120]
6. 3. 웹 스토리지
일부 웹 브라우저는 페이지가 정보를 로컬에 저장하여 나중에 사용할 수 있도록 하는 지속성 메커니즘을 지원한다.HTML5 표준(대부분의 최신 웹 브라우저가 어느 정도 지원)에는 로컬 스토리지와 세션 스토리지의 두 가지 유형의 스토리지를 허용하는 웹 스토리지라는 JavaScript API가 포함되어 있다. 로컬 스토리지는 지속형 쿠키와 유사하게 작동하는 반면, 세션 스토리지는 세션 쿠키와 유사하게 작동하지만, 세션 스토리지는 세션 쿠키와 같이 전체 브라우저 세션이 아닌 개별 탭/창의 수명(페이지 세션이라고도 함)에 묶여 있다.[104]
인터넷 익스플로러는 브라우저의 기록, 브라우저의 즐겨찾기, XML 저장소("사용자 데이터") 또는 디스크에 저장된 웹 페이지 내에서 지속적인 정보를 지원한다.[105]
일부 웹 브라우저 플러그인에는 지속성 메커니즘도 포함되어 있다. 예를 들어, Adobe Flash에는 로컬 공유 객체가 있고 Microsoft Silverlight에는 격리된 스토리지가 있다.[106]
7. 보안 및 개인 정보 보호 문제
HTTP 쿠키는 원래 웹의 단순한 파일 전송 기능을 넘어 사용자 맞춤형 서비스를 제공하기 위해 도입되었지만, 이로 인해 보안 및 개인 정보 보호 문제가 발생할 수 있다.
쿠키는 서버가 사용자를 식별하기 위해 브라우저에 저장하는 작은 텍스트 파일이다. 서버는 이 식별자를 통해 사용자에게 맞춤형 콘텐츠를 제공할 수 있지만, 제3자가 이 정보를 탈취하면 사용자를 사칭(세션 하이재킹)할 수 있다. 예를 들어 사용자가 웹사이트에 로그인하면 서버는 세션 ID를 쿠키 형태로 브라우저에 저장하고, 이후 사용자가 웹사이트를 이용할 때마다 브라우저는 쿠키를 서버에 전송하여 사용자를 식별한다. 만약 공격자가 이 쿠키를 훔치면 사용자인 척하며 서비스를 이용할 수 있다.
쿠키 정보는 전송 계층 보안(TLS)을 사용하지 않는 통신에서 도청될 수 있으며, 사이트 간 스크립팅 취약점을 통해 유출될 수도 있다. 또한, 사이트 간 요청 위조(CSRF) 공격에 사용될 수 있는데, 이는 사용자가 의도하지 않은 요청을 서버에 보내도록 하는 공격이다. 가령 공격자는 사용자의 은행 웹사이트에 자금 이체를 요청하는 이미지를 게시할 수 있다. 사용자가 이 이미지를 로드하면 브라우저는 사용자의 쿠키와 함께 이체 요청을 은행 서버에 전송하여 공격자가 사용자의 돈을 빼돌릴 수 있다.
쿠키 재킹은 사용자가 화면에서 객체를 드래그하도록 속여 사용자의 세션 쿠키를 훔치는 인터넷 익스플로러 공격이다.[96]
쿠키는 사용자의 웹 활동을 추적하는 데 사용될 수 있으며, 특히 여러 웹사이트에서 사용자를 추적하는 서드 파티 쿠키는 개인 정보 침해 문제를 야기할 수 있다. 미국 정부는 쿠키 사용에 대한 엄격한 규칙을 설정했으며, 중앙 정보국(CIA)과 국가 안보국(NSA)의 쿠키 사용이 문제가 된 적도 있다.[73]
쿠키는 사용자의 웹 이용 기록을 추적하는 데 사용될 수 있으며, 이는 행동 타겟팅 광고 등에 활용된다. 이러한 쿠키를 원치 않는 사용자는 보안 소프트웨어를 사용하여 트래킹 쿠키를 제거할 수 있다.[117][118]
7. 1. 세션 하이재킹 (Session hijacking)
대부분의 웹사이트는 사용자 세션의 유일한 식별자로 쿠키를 사용하는데, 이는 다른 사용자 식별 방법에 제한과 취약점이 있기 때문이다. 공격자는 피해자의 쿠키를 훔쳐 사용자의 요청을 가장할 수 있으며, 웹 서버는 이를 피해자의 요청으로 인식하여 세션이 하이재킹된다.다음은 HTTP 쿠키를 사용한 사용자 식별 웹사이트에서 쿠키 탈취 및 세션 하이재킹이 가능한 시나리오들이다.
- 네트워크 도청: 암호화되지 않은 네트워크 트래픽은 제3자에 의해 가로채 읽힐 수 있으며, 여기에는 HTTP 세션에서 전송된 쿠키가 포함된다. 공격자는 중간자 공격을 통해 쿠키를 훔쳐 사용자를 사칭하고, 피해자의 은행 계좌에서 돈을 이체하는 등의 악의적인 행위를 할 수 있다.[46] 이 문제는 전송 계층 보안(HTTPS 프로토콜)을 사용하여 연결을 암호화하고, 서버가 쿠키에 `Secure` 플래그를 설정하여 암호화된 채널을 통해서만 쿠키를 전송하도록 함으로써 해결할 수 있다.
- DNS 캐시 중독: 공격자가 조작된 DNS 항목을 캐시하도록 하면 사용자의 쿠키에 접근할 수 있다. 예를 들어, DNS 캐시 중독으로 공격자 서버 IP 주소를 가리키는 조작된 DNS 항목을 만들고, 이미지 URL(예: `http://f12345.www.example.com/img_4_cookie.jpg`)을 게시한다. 피해자가 이 이미지를 다운로드하면 `example.com` 관련 쿠키가 공격자 서버로 전송된다.[95] 이는 DNS 서버를 제대로 보호하지 않은 인터넷 서비스 제공업체의 잘못이지만, 대상 웹사이트가 보안 쿠키를 사용하면 공격의 심각성을 줄일 수 있다.
- 크로스 사이트 스크립팅(XSS): 공격자가 필터링되지 않은 HTML 및 JavaScript 콘텐츠를 게시할 수 있는 웹사이트를 악용하여, 악성 코드를 통해 피해자의 쿠키를 공격자가 제어하는 웹사이트로 전송하도록 할 수 있다.
예를 들어 공격자는 `www.example.com`에 다음과 같은 악성 링크를 게시할 수 있다.
```html
여기를 클릭하세요!
```
사용자가 이 링크를 클릭하면 `document.cookie`의 쿠키 목록이 `attacker.com` 서버로 전송된다. HTTPS 웹사이트라도 보안 쿠키가 일반 텍스트로 전송될 수 있다. 웹사이트 개발자는 이러한 악성 코드를 필터링해야 하며, HttpOnly 쿠키를 사용하면 클라이언트 측 스크립팅 언어로 쿠키에 접근할 수 없어 공격을 완화할 수 있다.
쿠키를 사용하여 세션 관리를 하는 경우, 제3자가 세션 ID를 알게 되면 원래 사용자인 척할 수 있다. 이러한 "사칭" 행위를 세션 하이재킹이라고 한다.
예를 들어, 다음과 같은 시스템에서
1. 홈페이지에서 사용자 ID와 비밀번호를 입력받는다.
2. 인증 성공 시 서버는 세션 ID를 할당하고 쿠키로 클라이언트에 알린다.
3. 클라이언트는 이후 요청에 쿠키로 세션 ID를 첨부하고, 서버는 세션 정보로 사용자를 식별한다.
제3자가 세션 ID를 알면 해당 세션 유효 기간 동안 1~2단계를 건너뛰고 3단계부터 시작하여 비밀번호 없이 "사칭"할 수 있다.
제3자가 쿠키 정보를 아는 방법 중 하나는 도청이며, TLS로 방지할 수 있다. 그러나 쿠키는 유효 범위 내 모든 요청에 자동 첨부되므로, SSL을 사용하지 않는 요청에도 첨부될 수 있다. 정보처리진흥기구(IPA)는 2003년 8월 이 점에 대한 주의를 환기했다.[116]
사이트 간 스크립팅도 쿠키 정보를 부당하게 얻는 수단이 될 수 있다. 쿠키 유효 범위 내에 사이트 간 스크립팅 취약점이 있는 페이지가 있으면, JavaScript 등으로 쿠키 정보를 다른 서버로 전송하게 할 수 있다.
7. 2. 사이트 간 요청 위조 (CSRF)
밥이 맬러리가 메시지를 게시한 채팅 포럼을 탐색하고 있다고 가정해 보자. 맬러리가 밥의 은행 웹사이트의 동작을 참조하는 HTML 이미지 요소를 만들었는데, 이미지 파일이 아닌 다음과 같은 형태를 띠고 있다.```xml
```
만약 밥의 은행이 그의 인증 정보를 쿠키에 저장하고 있고, 쿠키가 만료되지 않았다면, 밥의 브라우저가 이미지를 로드하려고 시도하면서 그의 쿠키와 함께 출금 양식을 제출하여 밥의 승인 없이 거래를 승인하게 된다.[110]
7. 3. 쿠키 재킹 (Cookiejacking)
쿠키 재킹은 공격자가 사용자가 화면에서 객체를 드래그하도록 속여 사용자의 세션 쿠키를 훔치는 인터넷 익스플로러 공격이다.[96] 마이크로소프트는 이 결함을 낮은 위험으로 간주했는데, 그 이유는 "요구되는 사용자 상호작용 수준"[96]과 쿠키가 훔쳐질 웹사이트에 사용자가 이미 로그인되어 있어야 한다는 점 때문이다.[97] 그럼에도 불구하고, 한 연구원은 자신의 페이스북 친구 150명을 대상으로 이 공격을 시도하여 소셜 엔지니어링을 통해 80명의 쿠키를 획득했다.[96]7. 4. 개인 정보 침해
사용자 프로필을 구축할 가능성은 특히 서드 파티 쿠키를 사용하여 여러 도메인에서 추적을 수행할 때 개인 정보 보호 위협이 된다. 이러한 이유로 일부 국가에서는 쿠키에 관한 법률을 제정했다.[72]미국 정부는 백악관 국가 마약 통제 정책 사무국이 쿠키를 사용하여 온라인 반마약 광고를 보는 컴퓨터 사용자를 추적한다는 사실이 밝혀진 후 2000년에 쿠키 설정에 대한 엄격한 규칙을 설정했다. 2002년, 개인 정보 보호 운동가 다니엘 브란트는 중앙 정보국(CIA)이 웹사이트를 방문한 컴퓨터에 지속적인 쿠키를 남겨두었다는 사실을 발견했다. 정책 위반 사실을 통보받은 CIA는 이러한 쿠키가 의도적으로 설정된 것이 아니라고 밝히고 설정을 중단했다. 2005년 12월 25일, 브란트는 국가 안보국(NSA)이 소프트웨어 업그레이드로 인해 방문자의 컴퓨터에 두 개의 지속적인 쿠키를 남겨두었다는 사실을 발견했다. NSA는 통보를 받은 후 즉시 쿠키를 비활성화했다.[73]
쿠키를 사용하면 해당 사용자의 다른 요청과 연결할 수 있다. 이 기법은 애드 네트워크(구글 애드센스 등)를 이용하는 웹 광고 업자가 자주 사용한다. 인터넷 광고 배포에서 배너 광고는 업체의 서버(서드 파티)로의 링크를 통해 이미지를 가져오는 형식이 일반적이다. 쿠키는 HTML뿐만 아니라 이미지에도 설정할 수 있다. HTTP에서는 링크 원본 URL 정보도 전송하는 것이 일반적이므로, 결과적으로 광고 업자는 동사를 이용하는 모든 사이트를 대상으로 해당 사용자의 액세스 기록을 파악하는 것이 가능해진다.
사용자의 액세스 기록을 추적한다는 의미에서 트래킹 쿠키라고 불리거나, 메인 HTML이 아닌 이미지 제공자가 설정한다는 의미에서 서드 파티 쿠키라고 불리기도 한다. 이것들은 행동 타겟팅 광고, 콘텐츠 연동형 광고, 검색 연동형 광고 등에 활용되며, 때로는 필터 버블의 원인이 되기도 한다.
이것을 개인 정보 침해라고 생각하는 사람도, 그렇게 생각하지 않는 사람도 있다. 이러한 쿠키를 설정하고 싶지 않은 사용자를 위해, 클라이언트용 보안 대책 소프트웨어의 대부분은 트래킹 쿠키를 감지·제거하는 기능을 갖추고 있다.[117][118]
8. 법적 규제
2019년 리쿠ナビ 운영 회사가 쿠키로 얻은 정보를 목적을 충분히 설명하지 않고 외부에 판매한 문제가 발각된 것을 계기로, 2022년 4월 1일 시행된 개인정보 보호법에 의해 쿠키 활용에 규제가 가해지게 되었다.[121][122]
8. 1. 대한민국
2019년 리쿠ナビ 운영 회사가 쿠키로 얻은 정보를 목적을 충분히 설명하지 않고 외부에 판매한 문제가 발각되면서, 2022년 4월 1일 시행된 개인정보 보호법에 따라 쿠키 활용에 규제가 가해지게 되었다.[121][122]8. 2. 유럽 연합 (EU)
2002년, 유럽 연합은 개인 정보 보호 및 전자 통신 지침(e-Privacy Directive)을 시행하여 쿠키 배치에 대한 최종 사용자의 동의를 요구했다.[74][75] 이 지침은 사용자가 요청한 서비스를 제공하는 데 기능적으로 필요한 쿠키 사용에 대한 권한 부여나 통지는 요구하지 않았다.[76]2009년, 이 법은 지침 2009/136/EC에 의해 수정되어 쿠키 저장을 위해 동의를 얻도록 요구했다.[75] 동의의 정의는 일반 데이터 보호 규정(GDPR)의 정의를 따르며, GDPR에서 동의 정의가 강화되면서 쿠키 사용에 요구되는 동의의 질도 높아졌다.[77] 많은 쿠키 정보는 GDPR에 의해 개인 데이터로 간주되어 처리를 위한 법적 근거가 필요하다.[78][79]
GDPR과 e-Privacy Directive에 따른 동의는 여러 조건을 충족해야 한다.[80] 동의는 자유롭고 명확하게 주어져야 하며, 사전 선택된 확인란은 금지된다.[77][81] 또한, 동의는 '제공만큼 쉽게 철회'되어야 하며,[81] 거부 버튼은 '모두 동의' 버튼만큼 접근하기 쉬워야 한다.[80] 동의는 구체적이고 정보를 제공해야 하며, 데이터 사용 목적과 동의를 사용하려는 모든 조직이 명시되어야 한다.[82][83] 유럽 연합 사법 재판소는 동의가 '효율적이고 시기적절'해야 한다고 판결하여, 쿠키 배치 및 데이터 처리 시작 전에 획득되어야 함을 의미한다.[84]
하지만, 학술 연구와 규제 기관은 법률 위반이 광범위하게 발생하고 있음을 지적한다.[80][86] 영국의 규제 기관인 정보 위원회 사무소는 2019년에 광고 기술 그룹인 상호 작용 광고국(Interactive Advertising Bureau)의 '투명성 및 동의 프레임워크'가 불충분하다고 밝혔다.[82]
일부 사이트는 '쿠키 벽'을 운영하여 사이트 접근을 쿠키 허용 조건으로 한다.[89] 2020년, 유럽 데이터 보호 위원회는 쿠키 벽이 불법이라고 밝혔다.[90]
8. 3. 미국
미국 연방 정부는 쿠키 사용에 대한 규제 및 정책을 가지고 있다. 국가 마약 통제 정책 사무국(ONDCP)은 웹사이트 방문자 추적에 쿠키를 사용한 것이 밝혀져 논란이 되었다. 중앙 정보국(CIA)과 국가 안보국(NSA)도 쿠키를 사용한다.[14]9. 브라우저 설정
대부분의 최신 웹 브라우저는 쿠키를 지원하며 사용자가 쿠키를 비활성화하거나 관리할 수 있도록 허용한다. 일반적인 옵션은 다음과 같다.[59]
- 쿠키를 완전히 활성화 또는 비활성화하여 항상 허용하거나 차단한다.
- 쿠키 관리자를 사용하여 쿠키를 보고 선택적으로 삭제한다.
- 쿠키를 포함한 모든 개인 데이터를 완전히 삭제한다.
쿠키 권한을 관리하기 위한 추가 도구(예: 브라우저 확장 프로그램)도 존재한다.[60][61][62][63]
현재 사용되는 대부분의 웹 브라우저는 쿠키를 송수신할 수 있으며, 초기 설정에서 쿠키를 송수신하도록 되어 있다. 그러나 쿠키의 송수신 여부와 그 내용은 웹 사용자의 자유 의지에 따라 결정되어야 하므로, 브라우저의 초기 설정에서 이를 조작할 수 있도록 되어 있다. 즉, 쿠키 송수신을 중지하거나, 쿠키 내용을 확인하거나, 쿠키를 삭제하는 기능이 웹 브라우저에 제공된다.
참조
[1]
웹사이트
What are cookies? What are the differences between them (session vs. persistent)?
https://www.cisco.co[...]
2018-07-17
[2]
웹사이트
Gmail cookie stolen via Google Spreadsheets
http://news.cnet.com[...]
2008-04-14
[3]
웹사이트
What about the "EU Cookie Directive"?
http://webcookies.or[...]
WebCookies.org
[4]
뉴스
New net rules set to make cookies crumble
https://www.bbc.co.u[...]
2011-03-08
[5]
웹사이트
Sen. Rockefeller: Get Ready for a Real Do-Not-Track Bill for Online Advertising
http://adage.com/art[...]
2011-05-06
[6]
웹사이트
Where cookie comes from :: DominoPower
http://dominopower.c[...]
[7]
웹사이트
magic cookie
http://catb.org/jarg[...]
[8]
뉴스
Giving Web a Memory Cost Its Users Privacy
https://www.nytimes.[...]
2001-09-04
[9]
논문
Deconstructing Code
2018-08-19
[10]
논문
HTTP Cookies: Standards, Privacy, and Politics
Association for Computing Machinery (ACM)
[11]
웹사이트
Press Release: Netscape Communications Offers New Network Navigator Free On The Internet
http://wp.netscape.c[...]
[12]
웹사이트
Usenet Post by Marc Andreessen: Here it is, world!
https://groups.googl[...]
1994-10-13
[13]
특허
Persistent client state in a hypertext transfer protocol based client-server system
[14]
뉴스
The history of Internet Explorer
https://www.microsof[...]
Microsoft
2005-08-25
[15]
논문
Online Privacy and the Disclosure of Cookie Use: Effects on Consumer Trust and Anticipated Patronage
http://journals.sage[...]
2008
[16]
뉴스
This Bug in Your PC is a Smart Cookie
1996-02-12
[17]
IETF
[18]
웹사이트
Setting Cookies
https://staff.washin[...]
2009-06-19
[19]
Webarchive
https://web.archive.[...]
2017-03-16
[20]
웹사이트
"'HTTP State Management Mechanism' to Proposed Standard"
http://www.thesecuri[...]
2011-03-06
[21]
웹사이트
Set-Cookie2 - HTTP {{!}} MDN
https://developer.mo[...]
[22]
웹사이트
Description of Persistent and Per-Session Cookies in Internet Explorer
http://support.micro[...]
2007-01-24
[23]
웹사이트
Maintaining session state with cookies
http://msdn.microsof[...]
[24]
논문
A Survey on Web Tracking: Mechanisms, Implications, and Defenses
https://ieeexplore.i[...]
2017
[25]
간행물
Exploring the Cookieverse: A Multi-Perspective Analysis of Web Cookies
https://link.springe[...]
Springer Nature Switzerland
2023
[26]
논문
CookiExt: Patching the browser against session hijacking attacks
https://www.medra.or[...]
2015-09-16
[27]
웹사이트
"'SameSite' cookie attribute, Chrome Platform tatus"
https://www.chromest[...]
[28]
논문
Same-Site Cookies draft-ietf-httpbis-cookie-same-site-00
https://tools.ietf.o[...]
2016-06-20
[29]
웹사이트
Using the Same-Site Cookie Attribute to Prevent CSRF Attacks
https://www.netspark[...]
2016-08-23
[30]
웹사이트
'Require "Secure" for "SameSite=None". by miketaylr · Pull Request #1323 · httpwg/http-extensions'
https://github.com/h[...]
[31]
보고서
Cookies: HTTP State Management Mechanism
https://datatracker.[...]
Internet Engineering Task Force
2020-12-07
[32]
웹사이트
Browser Compatibility Testing of 'SameSite' cookie attribute
https://www.lambdate[...]
[33]
웹사이트
SameSite Cookie Changes in February 2020: What You Need to Know
https://blog.chromiu[...]
[34]
웹사이트
Temporarily rolling back SameSite Cookie Changes
https://blog.chromiu[...]
[35]
웹사이트
Resuming SameSite Cookie Changes in July
https://blog.chromiu[...]
2020-05-28
[36]
웹사이트
Learn more about the Public Suffix List
https://publicsuffix[...]
2016-07-28
[37]
웹사이트
Tracking the Trackers: Microsoft Advertising
http://cyberlaw.stan[...]
The Center for Internet and Society
2011-08-19
[38]
웹사이트
Microsoft disables 'supercookies' used on MSN.com visitors
https://web.archive.[...]
2011-08-19
[39]
웹사이트
Firefox 85 Cracks Down on Supercookies
https://blog.mozilla[...]
2021-01-26
[40]
웹사이트
Zombie Cookie: The Tracking Cookie That You Can't Kill
https://www.propubli[...]
2020-11-01
[41]
웹사이트
The Cookie That Would Not Crumble!
https://24x7mag.com/[...]
2020-11-01
[42]
간행물
HTTP Cookies, A Promising Technology
Online Information Review
[43]
웹사이트
Real world cookie length limits
http://manicode.blog[...]
Jim Manico quoting Daniel Stenberg
[44]
간행물
Secure and efficient protection for HTTP cookies with self-verification
https://onlinelibrar[...]
2019-01-25
[45]
서적
Networked: The New Social Operating System
Rainie, Lee
2012
[46]
간행물
HTTP State Management Mechanism
[47]
웹사이트
Persistent client state HTTP cookies: Preliminary specification
http://wp.netscape.c[...]
Netscape
1999
[48]
웹사이트
Cookie Property
http://msdn2.microso[...]
Microsoft
2009-01-04
[49]
뉴스
Cookies, Set and retrieve information about your readers
http://www.yourhtmls[...]
HTMLSource
2007-02-26
[50]
간행물
HTTP State Management Mechanism, The Path Attribute
[51]
간행물
RFC 6265, HTTP State Management Mechanism, Domain matching
2014-03
[52]
간행물
RFC 6265, HTTP State Management Mechanism, The Domain Attribute
2014-03
[53]
웹사이트
Internet Explorer Cookie Internals (FAQ)
https://blogs.msdn.m[...]
2018-11-21
[54]
간행물
RFC 2109, HTTP State Management Mechanism, Set-Cookie syntax
2014-03
[55]
간행물
RFC 6265, HTTP State Management Mechanism
[56]
웹사이트
Cookies specification compatibility in modern browsers
https://inikulin.git[...]
2016
[57]
웹사이트
HTTP Cookies: What's the difference between Max-age and Expires? – Peter Coles
http://mrcoles.com/b[...]
2016-07-28
[58]
간행물
Symantec Internet Security Threat Report: Trends for July–December 2007 (Executive Summary)
https://web.archive.[...]
Symantec Corp.
2008-04
[59]
웹사이트
The Unofficial Cookie FAQ v2.6
http://www.cookiecen[...]
Cookie Central
2002-06-08
[60]
웹사이트
How to Manage Cookies in Internet Explorer 6
http://support.micro[...]
Microsoft
2007-12-18
[61]
웹사이트
Clearing private data
http://support.mozil[...]
Mozilla
2008-09-16
[62]
웹사이트
Clear Personal Information : Clear browsing data
https://www.google.c[...]
2009-01-04
[63]
웹사이트
Clear Personal Information: Delete cookies
https://www.google.c[...]
2009-01-04
[64]
웹사이트
Third party domains
http://webcookies.or[...]
WebCookies.org
2014-12-07
[65]
웹사이트
Number of cookies
http://webcookies.or[...]
WebCookies.org
2014-12-07
[66]
웹사이트
Apple updates Safari's anti-tracking tech with full third-party cookie blocking
https://www.theverge[...]
2020-03-24
[67]
웹사이트
Firefox starts blocking third-party cookies by default
https://venturebeat.[...]
2019-06-04
[68]
웹사이트
OK Google, don't delay real browser privacy until 2022
https://brave.com/ok[...]
2020-02-06
[69]
웹사이트
Chrome 83 arrives with redesigned security settings, third-party cookies blocked in Incognito
https://venturebeat.[...]
2020-05-19
[70]
웹사이트
Google can't quit third-party cookies—delays shut down for a third time
https://arstechnica.[...]
2024-04-24
[71]
웹사이트
Google's plan to turn off third-party cookies in Chrome is dying
https://www.theverge[...]
2024-07-22
[72]
논문
Online Privacy and the Disclosure of Cookie Use: Effects on Consumer Trust and Anticipated Patronage
2008
[73]
뉴스
Spy Agency Removes Illegal Tracking Files
https://www.nytimes.[...]
2005-12-29
[74]
웹사이트
EU Cookie Directive, Directive 2009/136/EC
http://www.jisclegal[...]
JISC Legal Information
2012-10-31
[75]
서적
Privacy and Electronic Communications Regulations
http://www.ico.gov.u[...]
Information Commissioner's Office
2012-10-31
[76]
웹사이트
Cookies and similar technologies
https://ico.org.uk/f[...]
2021-01-01
[77]
웹사이트
EUR-Lex - 62017CN0673 - EN - EUR-Lex
https://eur-lex.euro[...]
2021-06-06
[78]
Citation
Adtech and Real-Time Bidding under European Data Protection Law
https://osf.io/wg8fq
2021-04-01
[79]
간행물
Personal data processing for behavioural targeting: which legal basis?
2015-08
[80]
서적
Proceedings of the 2020 CHI Conference on Human Factors in Computing Systems
ACM
2020-04-21
[81]
웹사이트
EUR-Lex - 32016R0679 - EN - EUR-Lex
https://eur-lex.euro[...]
2021-06-06
[82]
서적
Update Report into Adtech and Real Time Bidding
https://cy.ico.org.u[...]
[83]
웹사이트
Délibération n° 2019-093 du 4 juillet 2019 portant adoption de lignes directrices relatives à l'application de l'article 82 de la loi du 6 janvier 1978 modifiée aux opérations de lecture ou écriture dans le terminal d'un utilisateur (notamment aux cookies et autres traceurs) (rectificatif)
https://www.legifran[...]
2021-06-06
[84]
웹사이트
EUR-Lex - 62017CC0040 - EN - EUR-Lex
https://eur-lex.euro[...]
2021-06-06
[85]
잡지
EU cookie law: stop whining and just get on with it
https://www.wired.co[...]
2012-05-24
[86]
서적
ICT Systems Security and Privacy Protection
Springer International Publishing
[87]
Citation
Consent Management Platforms Under the GDPR: Processors and/Or Controllers?
https://link.springe[...]
Springer International Publishing
2021
[88]
웹사이트
P3P: The Platform for Privacy Preferences
https://www.w3.org/P[...]
2021-10-15
[89]
간행물
Tracking Walls, Take-It-Or-Leave-It Choices, the GDPR, and the ePrivacy Regulation
http://edpl.lexxion.[...]
2017
[90]
웹사이트
Guidelines 05/2020 on consent under Regulation 2016/679 {{!}} European Data Protection Board
https://edpb.europa.[...]
2021-06-06
[91]
뉴스
A Loophole Big Enough for a Cookie to Fit Through
http://bits.blogs.ny[...]
The New York Times
2010-09-17
[92]
뉴스
How to Block Tracking Cookies
https://www.washingt[...]
2005-07-17
[93]
웹사이트
What's CNAME of your game? This DNS-based tracking defies your browser privacy defenses
https://www.theregis[...]
2021-06-06
[94]
arXiv
The CNAME of the Game: Large-scale Analysis of DNS-based Tracking Evasion
2021-03-05
[95]
웹사이트
Hack Obtains 9 Bogus Certificates for Prominent Websites; Traced to Iran - Threat Level - Wired.com
http://www.wired.com[...]
2011-03-23
[96]
웹사이트
Microsoft latest security risk: 'Cookiejacking'
https://www.reuters.[...]
2011-05-25
[97]
웹사이트
Security researcher finds 'cookiejacking' risk in IE
http://news.cnet.com[...]
2011-05-26
[98]
뉴스
Fielding Dissertation: CHAPTER 6: Experience and Evaluation
http://roy.gbiv.com/[...]
2000
[99]
웹사이트
REST Anti-Patterns
http://www.infoq.com[...]
InfoQ
2008-07-02
[100]
웹사이트
What Is a Browser Cookie?
https://www.howtogee[...]
2016-09-28
[101]
웹사이트
BrowserSpy
http://gemal.dk/brow[...]
gemal.dk
[102]
웹사이트
IE "default behaviors [sic]" browser information disclosure tests: clientCaps
http://mypage.direct[...]
Mypage.direct.ca
[103]
웹사이트
How Unique Is Your Web Browser?
https://panopticlick[...]
Electronic Frontier Foundation
2010-05-17
[104]
웹사이트
Window.sessionStorage, Web APIs {{!}} MDN
https://developer.mo[...]
[105]
웹사이트
Introduction to Persistence
http://msdn.microsof[...]
Microsoft
2014-10-09
[106]
웹사이트
Isolated Storage
http://msdn.microsof[...]
2014-10-09
[107]
문서
ここで言う資源とは、HTML文書や画像、音声、などのコンテンツ全般を指す。
[108]
문서
ウィキペディアを例に挙げると、同じURLでもログインしていない場合はページの一番上が「ログインまたはアカウント作成」、している場合は「(ユーザ名) 自分の会話 個人設定 ウォッチリスト 自分の投稿記録 ログアウト」と表示が変化する。
[109]
웹사이트
PERSISTENT CLIENT STATE HTTP COOKIES
https://web.archive.[...]
2011-09-29
[110]
웹사이트
2009-08-05-Dan-Winship.txt
https://raw.github.c[...]
2011-09-29
[111]
웹사이트
2009-08-11-Dan-Winship.txt
https://raw.github.c[...]
2011-09-29
[112]
문서
draft-ietf-httpbis-rfc6265bis-06
https://tools.ietf.o[...]
[113]
문서
Can I use: headers HTTP header: Set-Cookie: Cookie prefixes
https://caniuse.com/[...]
[114]
문서
Can I use: 'SameSite' cookie attribute
https://caniuse.com/[...]
[115]
웹사이트
[116]
웹사이트
経路のセキュリティと同時にセキュアなセッション管理を
https://www.ipa.go.j[...]
2008-05-24
[117]
웹사이트
시스템의 완전 스캔을 실행하면 트래킹 쿠키의 리스크가 표시된다
http://service1.syma[...]
2008-06-15
[118]
웹사이트
스파이웨어 검색을 하면 "COOKIE_・・・・"가 다량으로 검출되는데, 괜찮습니까?
http://www.trendmicr[...]
2008-06-15
[119]
뉴스
アドネットワークは、常にあなたを監視している
http://japan.interne[...]
japan.internet.com
2011-10-25
[120]
문서
Fingerprint해설사이트 - 明治大学 情報セキュリティ研究室
https://www.saitolab[...]
[121]
웹사이트
NTT컴온라인
https://www.nttcoms.[...]
NTT
2023-01-30
[122]
웹사이트
Cookieバナー多すぎ? ダークパターンに注意
https://www3.nhk.or.[...]
日本放送協会
2024-10-17
[123]
저널
Design & Implementation of License-based Digital Rights Management System
http://dx.doi.org/10[...]
2004-02-01
[124]
뉴스
Giving Web a Memory Cost Its Users Privacy
https://www.nytimes.[...]
2001-09-04
[125]
웹인용
Where cookie comes from :: DominoPower
http://dominopower.c[...]
2017-10-19
[126]
웹인용
magic cookie
http://catb.org/jarg[...]
2017-09-08
[127]
뉴스
Giving Web a Memory Cost Its Users Privacy
https://www.nytimes.[...]
2001-09-04
[128]
문서
Deconstructing Code
http://papers.ssrn.c[...]
[129]
간행물
HTTP Cookies: Standards, privacy, and politics
https://arxiv.org/ab[...]
[130]
웹인용
HTTP Cookies, A Promising Technology
Online Information Review
[131]
문서
Real world cookie length limits
http://manicode.blog[...]
2013-07-02
[132]
문서
HTTP State Management Mechanism, Apr, 2011
http://tools.ietf.or[...]
[133]
웹인용
Persistent client state HTTP cookies: Preliminary specification
http://wp.netscape.c[...]
Netscape
1999
[134]
웹인용
Cookie Property
http://msdn2.microso[...]
Microsoft
2009-01-04
[135]
뉴스
Cookies, Set and retrieve information about your readers
http://www.yourhtmls[...]
HTMLSource
2007-02-26
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com